Secure Sockets Layer (SSL) and Transport Layer Security (TLS), which is the successor to SSL, provide secure network connections. SSL and/or TLS are commonly used during web browsing (e.g., using HTTPS), email, and other Internet applications. SSL and TLS are described in several Request For Comments (RFCs), including RFC 2246 (describing TLS 1.0), RFC 4346 (describing TLS 1.1), RFC 5246 (describing TLS 1.2), and RFC 6101 (describing SSL 3.0).
An SSL or TLS client and server negotiate a set of parameters to establish a secure session in a process called a handshake. For example, the client first transmits a hello message (referred to as a ClientHello message) that includes the following: an indication of the requested version of the SSL or TLS protocol, a requested session identifier used to identify the session connection, a list of the cipher suites supported by the client, a list of the compression methods supported by the client, random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports. The extensions portion is covered by a set of RFCs and the Internet Assigned Numbers Authority (IANA) maintains the list of protocol parameters.
In response to the ClientHello message, the server transmits a hello message to the client (referred to as a ServerHello message) that includes the version of the SSL or TLS protocol supported by the server, a session identifier that will be used to identify the session, the selected cipher suite (selected from the list of cipher suites included in the ClientHello message), the selected compression method (selected from the list of compression methods included in the ClientHello message), random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random), and may include a list of the extensions that the server supports.
Following the hello message, the server transmits a list of its certificate(s) in a message referred to as a Certificate message (sometimes referred to as a Server Certificate message). The server then transmits a message indicating that the hello-message phase of the handshake is complete (referred to as a ServerHelloDone message). Typically for TLS sites, the certificate is chosen based on the IP address that is being connected to or based on the destination hostname included in a Server Name Indication (SNI) extension.
Different certificates are signed using different signature and hash algorithm pairs. Older clients may not support newer signature/hash algorithm pairs. On the other hand, older signature/hash algorithm pairs may not be secure. A client will experience degraded experience if it does not support the certificate used by the site. For instance, the client may display a warning or an ominous interstitial screen to the user; or may block the connection entirely.